너무 난잡한 에러코드

현재 프로젝트에서 프론트단에 API호출이 굉장히 많습니다. 물론 다른 프로젝트고 똑같겠죠. 그리고 비단 API뿐만이 아니라 모든 함수실행에 있어 try&catch문으로 예외처리를 하고있습니다.

에러가 났을경우 유저에게 당연히 에러사실을 인지시켜야 합니다. 그렇지 않으면 유저는 자신이 보고있는 화면이 제대로 전달된 화면인이 모를테니까요.

4개월 쯤 되었을때 이런생각을 하게됩니다.
이거 너무 불편하지 않나?

// 현재 에러 핸들링\
catch (err) {
      if (err?.response?.status === 502) {
        error('현재 업데이트중입니다. 잠시후 다시 시도해주세요');
      }
      console.log(err)
    }

현재의 에러 핸들링입니다.

에러발생시 객체에 리스폰스값을 참고하여 적당한 에러미시지를 추출하고, error()함수를 통해 에러 토스트를 출력하고 있습니다.

그런데 반드시 status코드로만 분간하는것이 아닙니다. 어떤것은 객체의 에러메시지를 넣어주는 경우가 있고, 어떤것은 백엔드와 프론트간의 통신을 위해서만 에러메시지를 넣은 경우가 있습니다.

당연히 이를 고대로 유저에게 노출시킬경우 유저는 어떠한 에러인지 제대로 인지하지 못하게 됩니다.

그리고 저 또한 매우 피곤한 코드를 작성하게 됩니다.

가령 에러객체안의 메시지가

const error = err.response?.data?.errors?.nonFieldErrors

console.log(error)
/* 'AttributeError: 카카오 사용자 정보를 가져올 수 없습니다.
 액세스 토큰이 잘못되었거나 만료되었을 수 있습니다.' */

이렇게 되어있을 경우 유저에게 저 내용 전부가 필요하지는 않습니다. 하지만 가공을 위해서는 어떤 에러인지를 알아야 할 필요가 있죠.

그러다보니 이런 경우도 생깁니다.

const error = err.response?.data?.errors?.nonFieldErrors

if (error.includes('duplicate')) {
  error('중복된 사용자입니다.')
}

백엔드에서 보내주는 에러코드도 무분별하고, 이를 받는 프론트의 에러핸들링도 무분별하다보니 모든 API에 대해서 개별적으로 에러핸들링을 해줘야했습니다.

백엔드와의 에러코드 표준화

이런 문제는 결국 제품과 유저의 소통을 힘들게하고, 개발자와 운영팀과의 소통이 힘들게 됩니다. 그리고 매번 새로운 에러메시지를 작성해야하는 저도 힘들죠.

그래서 해당 문제에대한 해결책을 몇가지 생각해보려합니다.첫번째로 백엔드와 에러코드 표준화를 진행합니다. 에러객체는 반드시 통일화 하며 저희 회사만에 에러코드를 만들게 됩니다.

넘버링을 100~900 까지로 나누며, 백단위로 관련된 에러를 묶고 에러메시지도 최대한 소통하기 편한쪽으로 작성할 예정입니다.

export const handlingErrorMessage = (errorCode: String) => {
  case '502'
    return '[에러코드 : 502] 로그인을 다시 시도해주세요'
  case '503'
    return '[에러코드 : 503] 중복된 유저입니다. 고객센터로 문의해주세요.'
  ...
}

더 나은 에러를 위해..

이 과정에서 좀더 좋은 에러를 출력하기 위해 많은 생각을 했습니다. 앞서 말했듯이 현재는 에러에 대한 메시지만을 토스트로 출력하고 있습니다.

하지만 유저는 그것을 좋은 에러라고 느끼지 못합니다. 해당에러가 어떤 에러였는지 알았다면 응당 그에 대한 해결책도 필요합니다.

그렇기에 단순 토스트창보다는 어떠한 액션이 있는 에러가 좋다고 생각했습니다. 가령 중복된 사용자의 경우 고객센터로 문의를 해줘야하는데 이 경우 단순히 닫기 대신 고객센터로 전화하는 버튼을 만들어준다면 유저는 좀 더 쉽게 해당 문제를 해결할 수 있을것입니다.

물론 이렇게 특정 액션을 해줄경우는 많지 않을거같지만, 적어도 단순 에러출력보다는 이 에러로 인해 유저가 어떤 행동을 해야하는지 유도해줘야겠다고 생각이 들었습니다.

이것이 모두 정답일수는 없겠지만, 아주 작은 편의성이라도 유저를 위해 더 개선시켜야겠다고 생각했습니다.

다음번에는 해당 코드표준화 작업 이후의 느낀점을 정리해보면 좋을거같습니다.